障害状況に備えて、DBインスタンスのデータベースを復旧できるように事前に準備することができます。必要な時にWebコンソールでバックアップを実行したり、定期的にバックアップが実行されるように設定できます。バックアップが実行されている間は当該DBインスタンスのストレージのパフォーマンス低下が発生する可能性があります。サービスに影響を与えないように、サービスの負荷が少ない時間にバックアップすることを推奨します。バックアップによるパフォーマンス低下を望まない場合は、高可用性構成を使用したり、リードレプリカでバックアップを実行することもできます。
[参考] 高可用性DBインスタンスは予備マスターでバックアップが行われ、マスターのストレージパフォーマンス低下が発生しません。
RDS for MySQLでは、Percona XtraBackupを利用してデータベースをバックアップします。外部MySQLのバックアップで復元したりRDS for MySQLのバックアップで復元するにはRDS for MySQLで使用するPercona XtraBackupと同じバージョンを使用する必要があります。DBエンジンバージョン別のPercona XtraBackupバージョンは次のとおりです。
MySQLバージョン | XtraBackupバージョン |
---|---|
5.7.15 | 2.4.28 |
5.7.19 | 2.4.28 |
5.7.26 | 2.4.28 |
5.7.33 | 2.4.28 |
5.7.37 | 2.4.28 |
8.0.18 | 8.0.32 |
8.0.23 | 8.0.32 |
8.0.28 | 8.0.32 |
8.0.32 | 8.0.32 |
8.0.33 | 8.0.33 |
8.0.34 | 8.0.34 |
8.0.35 | 8.0.35 |
[参考] 2023年8月17日XtraBackupユーティリティのバージョンがアップグレードされました。以前バックアップに使用されたXtraBackupバージョンはWebコンソールで確認できます。 高可用性DBインスタンスは予備マスターでバックアップが行われ、マスターのデータストレージの性能低下が発生しません。
バックアップ時に適用される設定項目は以下の通りで、自動バックアップと手動バックアップの両方に適用されます。
テーブルロックの使用
FLUSH TABLES WITH READ LOCK
構文を実行するかどうかを設定します。FLUSH TABLES WITH READ LOCK
構文を実行します。FLUSH TABLES WITH READ LOCK`構文の実行に失敗した場合、バックアップに失敗します。FLUSH TABLES WITH READ LOCK
構文を実行しないため、DML負荷が多くてもバックアップが失敗しません。しかし、テーブルロックを使用しないバックアップは、バックアップデータの一貫性が保証されない可能性があり、これにより、テーブルロックを使用せずに作成されたバックアップおよびテーブルロックを使用しないように設定されたDBインスタンスに対する復元および複製過程を含む一部の作業をサポートしません。クエリ遅延待機時間(秒)
FLUSH TABLES WITH READ LOCK
構文の待機時間を設定します。クエリ遅延待機時間だけFLUSH TABLES WITH READ LOCK
構文が待機します。0~21,600秒まで設定できます。長く設定するほど、DMLクエリの負荷によるバックアップ失敗の可能性を減らすことができますが、全体のバックアップ時間が長くなる可能性があります。特定の時点のデータベースを永久に保存するには、Webコンソールから手動でバックアップを実行することができます。手動バックアップは自動バックアップと異なり、明示的にバックアップを削除しない限り、DBインスタンスが削除されるときと同じように削除されません。手動バックアップの場合、バックアップの名前を入力する必要があり、下記のような制約があります。
手動でバックアップを実行する場合以外にも、復元作業のために必要な場合、または自動バックアップスケジュールの設定によって自動バックアップが実行されることがあります。自動バックアップはDBインスタンスとライフサイクルが同じです。DBインスタンスが削除されると、保管された自動バックアップはすべて削除されます。自動バックアップでサポートする設定項目は下記の通りです。
自動バックアップを許可
自動バックアップの保管期間
自動バックアップ複製リージョン
自動バックアップの再試行回数
**自動バックアップスケジュールの使用
バックアップ実行時間
自動バックアップの名前は{DBインスタンスの名前}_yyyy-MM-dd-HH-mm
の形で付与されます。
[注意] 前のバックアップが終了していないなど、バックアップを実行できない状況ではバックアップが実行されない場合があります。
すべてのバックアップファイルは、内部バックアップストレージにアップロードして保存します。手動バックアップの場合、別途削除するまで永続的に保存され、バックアップ容量に応じてバックアップストレージの料金が発生します。自動バックアップの場合、設定した保管期間だけ保存され、自動バックアップファイルの全体サイズのうち、DBインスタンスのストレージサイズを超過した容量に対して課金されます。バックアップファイルが保存されている内部バックアップストレージに直接アクセスすることはできず、バックアップファイルが必要な場合は、NHN Cloudのオブジェクトストレージにバックアップファイルをエクスポートできます。
内部バックアップストレージに保存されたバックアップファイルをNHN Cloudのユーザーオブジェクトストレージにエクスポートできます。手動バックアップまたは自動バックアップファイルをエクスポートしたり、バックアップを実行すると同時にバックアップファイルをユーザーオブジェクトストレージにエクスポートすることもできます。バックアップをエクスポートしている間、元のDBインスタンスのネットワーク性能の低下が発生する場合があります。
[参考] 手動バックアップの場合、バックアップを実行した元DBインスタンスが削除されると、バックアップをエクスポートできません。
バックアップを利用して希望の時点にデータを復元できます。復元時には常に新しいDBインスタンスが作成され、既存のDBインスタンスに復元することはできません。バックアップを実行した元のDBインスタンスと同じDBエンジンのバージョンにのみ復元できます。バックアップが作成された時点に復元するスナップショット復元、希望する特定の時点に復元する時点復元をサポートします。RDS for MySQLで作成したバックアップだけでなく、外部MySQLのバックアップにも復元できます。
[注意] 復元するDBインスタンスのデータストレージサイズがバックアップを実行した元のDBインスタンスのストレージサイズより小さい場合や、元のDBインスタンスのパラメータグループと異なるパラメータグループを使用する場合、復元に失敗することがあります。
スナップショット復元は、バックアップを実行した時点に復元します。バックアップファイルだけで復元を行い、バックアップを行った元のDBインスタンスが必要ありません。
時点復元を利用して、希望する特定の時点またはバイナリログ(binary log)の特定の位置に復元できます。時点復元をするためには、バックアップファイルとバックアップを実行した時点から復元を希望する時点までのバイナリログ(binary log)が必要です。バイナリログ(binary log)は、バックアップが行われる元DBインスタンスのストレージに保存されます。バイナリログ(binary log)の保管期間が短い場合、ストレージ容量をより多く使うことがありますが、希望する時点への復元が難しい場合があります。下記の場合、時点復元に必要なバイナリログ(binary log)がないため、希望の時点に復元できない場合があります。
外部MySQLバックアップファイルを利用してDBインスタンスを作成できます。外部MySQLバックアップファイルを作成する時、バックアップ項目を参照してRDS for MySQLで使用するPercona XtraBackupと同じバージョンを使用する必要があります。
[注意] innodb_data_file_pathの設定値がibdata1:12M:autoextendでない場合、RDS for MySQLのDBインスタンスに復元できません。
(1) MySQLがインストールされたサーバーで下記のコマンドを利用してバックアップを実行します。
XtraBackup 2.4.xx例
innobackupex --defaults-file={my.cnfパス} --user {ユーザー} --password '{パスワード}' --socket {MySQLソケットファイルのパス} --compress --compress-threads=1 --stream=xbstream {バックアップファイルが作成されるディレクトリ} 2>>{バックアップログファイルのパス} > {バックアップファイルのパス}
XtraBackup 8.0.xx例
xtrabackup --defaults-file={my.cnfパス} --user={ユーザー} --password='{パスワード}' --socket={MySQLソケットファイルのパス} --compress --compress-threads=1 --stream=xbstream --backup {バックアップファイルが作成されるディレクトリ} 2>>{バックアップログファイルのパス} > {バックアップファイルのパス}
(2)バックアップログファイルの最後の行にcompleted OK!があるか確認します。
completed OK!`がない場合は、バックアップが正常に終了していないため、ログファイルにあるエラーメッセージを参照してバックアップを再度行います。
(3)完了したバックアップファイルをオブジェクトストレージにアップロードします。
(4)復元するプロジェクトのWebコンソールに接続した後、DBインスタンスタブでオブジェクトストレージにあるバックアップで復元ボタンをクリックします。
[注意] 現在5.7.33バージョンでは、オブジェクトストレージのバックアップファイルを利用したDBインスタンスの復元は制限されます。 推奨するXtraBackup以外のバージョンを使用すると、正常に動作しない場合があります。 オブジェクトストレージのバックアップファイルと復元しようとするMySQLのバージョンは同じでなければなりません。
RDS for MySQLのバックアップファイルを利用して直接MySQLのデータベースを復元することができます。RDS for MySQLのバックアップファイルを復元する時、バックアップ項目を参照してRDS for MySQLで使用するPercona XtraBackupと同じバージョンを使用する必要があります。
(1) バックアップのエクスポートの項目を参照して、RDS for MySQLのバックアップをオブジェクトストレージにエクスポートします。
(2)オブジェクトストレージのバックアップを復元したいサーバーにダウンロードします。
(3) MySQLサービスを停止します。
(4) MySQLデータ保存パスのすべてのファイルを削除します。
rm -rf {MySQLデータ保存パス}/*
(5)ダウンロードしたバックアップファイルを解凍して復元します。
XtraBackup 2.4.xxの例
cat {バックアップファイル保存パス} | xbstream -x -C {MySQLデータ保存パス}
innobackupex --decompress {MySQLデータ保存パス}
innobackupex --defaults-file={my.cnfパス} --apply-log {MySQLデータ保存パス}
XtraBackup 8.0.xxの例
cat {バックアップファイルの保存パス} | xbstream -x -C {MySQLデータ保存パス}
xtrabackup --decompress --target-dir={MySQLデータの保存パス}
xtrabackup --prepare --target-dir={MySQLデータ保存パス}
xtrabackup --defaults-file={my.cnfパス} --copy-back --target-dir={MySQLデータ保存パス}
(6)解凍後、不要なファイルを削除します。
find {MySQLデータ保存パス} -name "*.qp" -print0 | xargs -0 rm
(7) MySQLサービスを起動します。